Wzorzec Try-Catch w Microsoft Flow
Table of Contents
Ostatnio miałem przyjemność zaprezentować swoje demo podczas Microsoft Flow Online Conference 2019 na temat budowania bezbłędnych przepływów pracy w Microsoft Flow. W rzeczywistości chodziło raczej o rejestrowanie i debugowanie, aby w końcu otrzymać bezbłędne przepływy pracy.
Poniżej możesz obejrzeć nagranie z konferencji:
Bezbłędne przepływy
Każdy, kto ma nawet małe doświadczenie w programowaniu, zna wzorzec „try catch”, zwykle wspierany blokiem „finally”. Ta konstrukcja służy do obsługi błędów w częściach kodu, w których programiści spodziewają się wystąpienia błędów. Jeśli zostanie wykryty błąd, nie uruchomi nieobsługiwanego wyjątku i nie spowoduje zawieszenia się aplikacji, ale pozwoli go przechwycić i zarządzić, aby aplikacja działała bez zakłóceń lub przynajmniej by użytkownika powiadomić, co się zdarzyło.
To samo podejście można zastosować w przypadku Microsoft Flow. Nawet gdy budujemy przepływ, starając się zrobić wszystko, co w naszej mocy, przewidując wszystkie możliwe wyjątki w sposobie działania Flow, nadal możemy być zaskoczeni sytuacjami całkowicie niezależnymi od nas, np. treść JSON uległa zmianie i nie jest zgodna ze schematem, secret key wygasł i Flow został pozbawiony dostępu lub ktoś usunął element z bazy danych, który był używany jako słownik, lub schemat encji zmienił się i tak dalej.
Wzorzec Try-Catch w Microsoft Flow
Gdy postanowisz poszukasz w Internecie sposobu implementacji takiego wzorca, możesz dość łatwo znaleźć już istniejące rozwiązania:
- Rob Windsor: https://blogs.msmvps.com/windsor/2019/04/25/microsoft-flow-error-handling/
- Serge Luca: https://sergeluca.wordpress.com/2018/03/12/pattern-for-microsoft-flow-error-handling/
- Marcel Haas: https://www.thatmarcelhaas.com/post/advanced-error-handling-in-microsoft-flow
- Pieter Veenstra: https://veenstra.me.uk/2018/06/06/microsoft-flow-advanced-error-handling-throw-in-flow/
Istnieje już gotowy szablon wzorca w galerii szablonów Microsoft Flow, który możesz użyć od razu: https://flow.microsoft.com/en-us/galleries/public/templates/e8e028c6df7b4eb786abdf510e4f1da3/try-catch-and-finally-template/
Powyższe przykłady są mniej lub bardziej złożone, jednak wszystkie opierają się na dwóch funkcjach Microsoft Flow:
Run after
Ta funkcja służy do konfigurowania relacji i uruchamiania reguł sekwencji między akcjami. Pozwala ustawić, że następna akcja powinna zostać uruchomiona, jeśli poprzednia: zakończyła się pomyślnie, nie powiodła się, została pominięta lub upłynął limit czasu na jej wykonanie.
Aby uzyskać dostęp do tego ustawienia, wystarczy kliknąć ikonę epsilon (1), a następnie z menu kliknąć „Configure run after” (2), następnie zdefiniować relację (3) i na koniec zapisać zmiany (4).
Scope
Scope jest dedykowany do grupowania akcji, dzięki czemu później można go zwinąć (ukrywając akcje w jego wnętrzu), aby duży przepływ pracy wyglądał na mniejszy i łatwiejszy do odczytania. To jest jak „step” w przepływach pracy SharePoint Designer. W scenariuszu obsługi błędów Scope ma również do odegrania drugą, ważną rolę: jeśli wystąpi w jego wnętrzu błąd, zostanie to zaznaczone na poziomie akcji Scope: cała akcja będzie posiadać status błędu.
Aby dodać scope, kliknij, aby dodać nową akcję, a następnie wpisz „Scope”. Gotowe.
Obsługa błędów w Microsoft Flow
Wzorzec Run after i blok równoległy
Pierwsze podejście opiera się tylko na konfiguracji „Run after” i akcji równoległej (parallel branch). Aby to osiągnąć, po prostu dodaj strukturę równoległą po działaniu, które podejrzewasz, że może zakończyć się błędem, a następnie w lewej gałęzi wstaw akcje, które mają być wykonane gdy nie będzie błędu, zaś po prawej akcję wysyłania wiadomości e-mail:
Następnie skonfiguruj „Run after” akcji po lewej stronie, aby działała tylko wtedy, gdy poprzednia zakończy się pomyślnie, a następnie tej po prawej stronie, aby działała tylko wtedy, gdy poprzednia zakończy się niepowodzeniem lub upłynie limit czasu na jej wykonanie, lub zostanie pominięta:
Po prawidłowym skonfigurowaniu zauważysz, że prawa ścieżka jest zaznaczona czerwoną, przerywaną linią, informując, że jej „run after” jest ustawiony na uruchomienie, gdy poprzednia akcja nie powiedzie się:
Wzorzec Run after i scope
To zaawansowana konfiguracja korzystająca z trzech akcji „Scope”: Try”, „Catch” i „Finally”. Bazuje na szablonie znajdującym się tutaj: https://flow.microsoft.com/en-us/galleries/public/templates/e8e028c6df7b4eb786abdf510e4f1da3/try-catch-and-finally-template/.
Scope „Try” powinien zawierać wszystkie akcje z głównego przepływu procesu. Scope „Catch” jest skonfigurowany do uruchamiania tylko wtedy, gdy „Try” nie powiedzie się (z jakiegokolwiek powodu). Następnie scope „Finally” powinien działać bez względu na to, co stanie się z poprzednimi akcjami:
Rob Windsor zauważył, że istnieje funkcja „result()
”, której można używać w Logic Apps. Ponieważ jednak Flow jest zbudowany na Logic Apps, funkcja jest w nim również dostępna. Pobiera ona tablicę JSON ze szczegółami wykonania akcji z wnętrza scope, przekazywanego jako parametr. Ja używam tej funkcji w scope „Catch”.
Scope „Catch”
Najpierw filtruję tablicę zwróconą przez funkcję „result('Try')
”. Jak napisałem powyżej – zawiera ona wszystkie szczegóły dotyczące wykonania każdej akcji z zakresu „Try”. Używam tu akcja Filter by usunąć z listy informacje o akcjach, których uruchomienie nie zakończyło się statusem „Failed” lub „TimedOut”.
Następnie dla każdego, takiego elementu dołączam jego szczegóły do zmiennej tekstowej, która następnie jest przesyłana do mnie e-mailem, dzięki czemu mam pełne informacje o błędach.
Scope „Finally”
W moim przypadku służy zawsze do zwracania odpowiedzi – ponieważ Flow jest wywoływany za pośrednictwem żądania HTTP:
Ale w zależności od scenariusza kod odpowiedzi ma wartość 200 lub jest ustawiony odpowiednio do błędu wychwyconego przez scope „Catch”, np. 400 lub 401.
Słowo końcowe
Pamiętaj – możesz używać tych wzorców tak często w Flow, jak potrzebujesz. Równie dobrze możesz wdrożyć wiele wzorców Try-Catch-Final w ramach jednego przepływu. Wszystko zależy od konkretnych wymagań.
I to wszystko! Mam nadzieję, że te wzorce okażą się przydatne. Jeśli potrzebujesz wsparcia: zostaw komentarz lub napisz do mnie maila.
Przemek
Witam,
czy jest jakiś sposób na to żeby po zakończeniu takiego flow z obsługą błędów jest status nie był failed? Mam proste flow które korzysta z Get row i jeśli get row zwraca kod 404 to robi Add row i wszystko jest ok. Pomimo tego, że jet to błąd oczekiwany i obsłużony status flow i tak jest failed.
Tomasz Poszytek
Czyli musi być jakiś błąd w obsłudze błędu. Normalnie, jeśli błąd jest obslużony i dalszy przepływ odbywa się bez zakłóceń, wynik flow powinien być pozytywny.
Ewentualnie możesz użyć akcji „Terminate”, żeby zakończyć przepływ wcześniej i w ustawieniach akcji wybrać sposób zakończenia jaki potrzebujesz.